1. Field of the Present Invention
The invention is in the field of data processing networks and more particularly in the field of data processing networks in which remote objects are locally invoked.
2. History of Related Art
JAVA™.RTM. (JAVA™ is a trademark of SUN MICROSYSTEMS™) Remote Method Invocation (RMI) enables a programmer to create distributed JAVA™ applications in which the methods of remote JAVA™ objects can be invoked from other JAVA™ Virtual Machines (JVM™s), typically on different host systems. JAVA™ RMI is described in greater detail in the JAVA™ Remote Method Invocation Specification (Rev 1.9), from SUN MICROSYSTEMS™ A remote object is defined as an object that implements the java.rmi.remote interface. For purposes of this disclosure, however, a remote object may be thought of as an object that is not loaded into the JVM™ that is attempting to call it.
A JAVA™-based program can make a call to a remote object once it obtains a reference to the remote object, either by looking up the remote object using a naming service provided by RMI or by receiving the reference as an argument or a return value. A client can call a remote object in a server and that server can also be a client of other remote objects.
RMI uses object serialization to marshal and unmarshal arguments for remote object calls. Object serialization refers to the ability to read or write an entire object to and from a raw byte stream. It allows JAVA™ objects and primitives to be encoded into a byte stream suitable for streaming to some type of network, to a file-system, or more generally to a transmission medium or storage facility.
Referring to FIG. 1, a conceptual representation of traditional Java remote object invocation is depicted. In the depicted embodiment, a JAVA™ source code file (a .java file) 102 is compiled by javac compiler 106 on a client-side computer 101 to create JAVA™ byte code (a .class file) 110 that is executable by a JAVA™ Runtime Environment (JRE), which includes a Java Virtual Machine (JVM™). JRE's and JVM™'s are well known in the field of JAVA™ programming.
Before executing the client-side application (i.e., the class file 110), an RMI compiler (rmic) 114 is used to create a stub file 118 and a tie or skeleton file 122. (Tie files are created in an embodiment based on the Internet Inter-orb Protocol (IIOP) while skeleton files are created in an embodiment based on the JAVA™ Remote Method Protocol (JRMP)). The stub file 118 is a proxy for the remote object. Stub file 118 is responsible for forwarding method invocations on remote objects to the server where the actual remote object implementation resides. Tie file 122 is the server-side analogy of stub file 118. Tie file 122 is used for returning objects and parameters to the client-side application.
Class file 110 contains a reference to a remote object 130 that is actually a reference to stub 118. When class 110 makes a call to remote object 130, stub 118 is the class file by which the remote object call is forwarded to the server where the remote object resides. Stub 118 performs this function by serializing the remote object call parameters and sending the serialized byte stream over the network using conventional TCP/IP. Tie file 122 performs a similar function on the remote object server-side.
Referring to FIG. 2, a conceptual representation of a conventional JAVA™ RMI run time sequence is presented. In the illustrated example, a class file 110 being executed by a corresponding JVM™ (not depicted) contains a call to a remote object 130. When the call to remote object 130 is executed, the remote call is effected through stub file 118. More specifically, a call to remote object 130, including any parameters and objects that are needed by the remote object, is passed (as represented by reference numeral 202) to the stub file 118. Stub file 118 is responsible for serializing the remote object call and the call's arguments and for sending (204) the serialized byte stream to a server-side JVM™ (not depicted) under which the remote object executes.
In the depicted illustration, the Java application file 110 and the remote object 130 reside on different machines with JAVA™ application file 110 being shown as residing on a “client-side” computer 201 and the remote object residing on a “server-side” computer 203. In this configuration, the communication of serialized bytes streams between client side 201 and server side 203 is preferably achieved using a conventional network protocol stack such as TCP/IP.
On server-side 203, a tie file 122 receives the serialized byte stream sent by stub file 118 and de-serializes or un-marshals the corresponding arguments to reconstruct the objects and parameters of the remote object call. The de-serialized objects and/or parameters are delivered (reference numeral 206) to remote object 130 for execution. Remote object 130 then executes server side 203 using the received objects and/or parameters and produces a resulting set of parameters and/or objects that are returned (reference numeral 208) to tie file 122. Tie file 122 serializes the arguments and sends (210) the serialized data back to client-side 201. Stub file 118 is then responsible for un-marshaling the serialized objects and parameters before returning (reference numeral 212) the un-serialized data to the client-side application.
Under certain circumstances, a stub for a particular remote object is not present on the client-side system and a “ClassNotFoundException” is generated. This situation can occur, for example, when the client side application does not have a direct reference for a remote object but instead retrieves a reference to a remote object from a naming service like JAVA™ Naming and Directory Service (JNDI). In this case, since one cannot anticipate at compile time what remote object will be returned by a call to the naming service, the programmer cannot assure that an appropriate stub will be present. In another example, a client-side call to a first remote object returns to the client-side a reference to a second remote object (either as a parameter in a call originated by the first remote object or as a return value to the client-side remote object call). In this situation, the name of the remote object that is returned from the server side is not knowable at compile time and the appropriate stub may not be present on the system. It would be desirable to eliminate this source of errors by implementing a method and system for creating “missing” stub class files to accommodate remote object calls that a client device needs to make. It would be further desirable if the implemented solution operated dynamically at run time to improve run time performance and reduce the amount of undesirable re-compilation.